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REMARKS 

[OOOl] Claims I -26, and 28 are pending. The Office Action mailed August 10, 2006 
(hereinafter "Office Action") rejected claims 1-13, 15-26, and 28 under 35 U.S.C. § 102(b) as 
being anticipated by Dunham, et al., U.S. Patent No. 6,269,43 1 (hereinafter "Dunham' 1 ). The 
Office Action rejected claim 14 under 35 U.S.C. § 103(a) as being unpatentable over Dunham in 
view of Asano, U.S. Patent Publication No. 2003/0191909 (hereinafter "Asano"). 

AMENDMENTS TO THE CLAIMS 

[0002] The claims have been amended to more particularly point out the features of the 
present invention. In particular, claims 1, 4, 12, 16, 23, 24, and 28 are amended to clarify that the 
storage volumes are allocated and de-allocated to the storage pool to change the storage capacity 
of the virtual volume. The amendments are fully supported by the specification, drawings, and 
claims. In particular, the amended claims are supported by paragraphs 1 1, 17, 18, 20, 50, 52-54, 
63, and 64 of the Application of David A. Burton, et al., filed 1 1/14/2003, application no. 
1 0/7 1 3,445 (hereinafter "Application"). 

REJECTION OF CLAIMS 1-13. 15-26. AND 28 UNDER 35 U.S.C. §102(bl 

[0003] The Examiner rejected claims 1-13, 15-26, and 28 under 35 U.S.C. §102(b) as 
being anticipated by Dunham. The Applicants respectfully traverse this rejection. "Anticipation 
under 35 U.S.C. §102 requires the disclosure in a single piece of prior art of each and every 
limitation of a claimed invention. . . .Whether such art is anticipating is a question of fact." Apple 
Computer, Inc. v. Articulate Systems, Inc. 234 F.3d 14, 20, 57 USPQ2d 1057, 1061 (Fed. Cir. 
2000), It is well settled that under 35 U.S.C. §102 "an invention is anticipated if . . . all the claim 
limitations [are] shown in a single art prior art reference. Every element of the claimed invention 
must be literally present, arranged as in the claim. The identical invention must be shown in as 
complete detail as is contained in the patent claim." Richardson v. Suzuki Motor Co., Ltd, 9 
U.S.P.Q.2d 1913, 1920 (Fed. Cir. 1989). In determining whether a prior art reference anticipates 
a claim, it is necessary to (1) determine the scope of Applicant's broadest claim, (2) determine 
exactly what the single prior art reference discloses, and (3) compare each and every claim 
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limitation against the prior art disclosure. SSIH Equipment, S.A. v. U.S Int'l Trade Commission 
et al y 218 U.S.P.Q. 678, 688. Only if each limitation is literally disclosed by the prior art 
reference is the claim anticipated. 

[0004] Initially, it may be useful to review the invention described in the Application and 
the disclosures of the prior art. In general, the Application describes an incremental backup 
system where a baseline copy of a primary volume is stored on a baseline volume and 
incremental changes to the primary volume are stored on a virtual storage volume mapped to a 
storage pool. Application at Fig. 2, fflf 6, 39-40. A policy management module sets a storage 
management policy for storage capacity of the virtual volume. Id. at 1}52. A storage pool 
management module monitors available storage capacity of the virtual volume and changes the 
storage capacity based on the storage management policy and available storage capacity. Id. at ffij 
50-55. The storage pool management module changes the storage capacity of the virtual volume ■■ 
by allocating or de-allocating storage volumes to the storage pool. Id. 

[0005] By contrast, Dunham teaches managing virtual storage of spare storage capacity 
on a primary volume or allowing direct block level access to data on a secondary storage volume 
during a data recovery operation. Dunham at Abstract, col. 1, 1. 60 to col. 4, 1. 23. Dunham 
repeatedly teaches a system that backs up an entire volume or file structure. Id. at col. 5, 11. 26- 
32, col. 5, 1. 65 to col. 6, 1. 4, col. 1 1, li. 41-46, col. 1 1, 1. 64 to col. 12, 1. 2, col. 12, 11. 31-34, col. 
13, 11. 45-48. Dunham teaches that when a recovery operation is required, that a copy of the 
backup to be restored must be copied to the spare capacity in the primary volume or made 
directly accessible from the secondary volume. Id. at col. 18, 11. 27-64; see also id. at col. 16, 1. 
53 to col. 17, Fig. 9. 

[0006] Dunham teaches that when sufficient capacity is available on the primary storage 
unit, the spare capacity is mapped to a virtual volume and the backup to be restored is copied to 
the new virtual volume. Id. at Fig. 15, col. 21, 11. 16-63. After the primary volume is restored, 
the virtual volume is returned for general use. Id. at col. 21, 1. 64 to col. 22, 1. 3. If there is 
insufficient spare capacity on the primary volume, the backup is retrieved from the tape storage 
of the secondary volume and moved to the disk storage of the primary volume. Id. at Fig. 15, 
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col. 22, 11. 4-20. The backup is then made accessible to the primary for the restoration and then 
the storage in the disk storage of the secondary volume is released. Id. 

[0007] With regard to claims 1, the Office Action states that Dunham discloses a storage 
pool configured to store incremental storage data from an incremental storage operation on a 
primary volume and cites the secondary storage 29 'of Figure 1 and column 19, lines 36-47 of 
Dunham. Office Action at p. 2-3. The Applicants disagree. Dunham does not teach, disclose, or 
suggest an incremental storage operation, but instead teaches backups and snapshot copies of an 
entire volume, A search of the entire specification and claims of Dunham reveals that Dunham 
does not even contain the word incremental. See generally Dunham, 

[0008] Dunham repeatedly teaches that a backup is made of an entire volume or file 
system and, in fact, teaches away from an incremental backup. Id. at col. 5, 11. 26-32, col. 5, 1. 65 
to col. 6, 1. 4, col. 1 1, 11. 41-46, col. 1 1, 1. 64 to col. 12, 1. 2, col. 12, 11. 31-34, col. 13, 11. 45-48. 
Dunham teaches away from storing incremental changes by teaching combining backup requests 
of users "since a backup copy of the entire file system will be made." Id. at col. 13, 11. 39-48. 
The Applicants respectfully assert that Dunham does not anticipate claim 1 because Dunham 
does not teach storing incremental storage data from an incremental storage operation on a 
primary volume and actually teaches away from incremental storage operations. 

[0009] The Office Action also states that Dunham discloses "a storage pool management 
module (backup agent - Fig. 1, element 25) configured to monitor available storage capacity of 
the storage pool and to change the storage capacity in response to the storage management policy 
and the available storage capacity (the backup agent responds to a request made by the host for a 
backup (i.e. change in storage capacity). The backup agent monitors the capacity by checking if 
any spare primary storage is available - Fig. 15 flowchart, col. 21, lines 16-63), wherein 
changing the storage capacity comprises allocating and de-allocating a storage volume to the 
storage pool in response to the change to the storage capacity (Fig. 15, if a spare volume is 
available, the next virtual volume will be assigned to it - col. 21, lines 16-63)." Office Action at 
p. 3. The Applicants disagree. 
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[00 10] Dunham teaches checking for spare capacity on the primary volume only as part 
of a backup recovery operation, Dunham at Fig. 15 (first step of flow chart), col 21, 11. 16-20, 
not as part of an incremental storage operation. See Application at amended claim 1 . In 
addition, Dunham teaches locating spare storage that is part of the primary volume, Dunham at 
Fig. 15, steps 41, 42, col. 21, 11. 20-29, not changing storage capacity of a virtual volume that is 
mapped to a storage pool. Application at Fig. 2, amended claim 1. The Office Action states in 
one instance that the storage pool corresponds to the secondary storage 29, Figure 1 of Dunham, 
but then states that the actions of storage pool management module to change the storage 
capacity of the storage volume correspond to locating spare capacity in the primary volume. 
Office Action at p. 3. The statements are inconsistent -and further demonstrate that Dunham does 
not anticipate claim 1 . In addition, monitoring and changing the storage capacity of the storage 
pool is not equivalent to the actions of the backup agent 25, Figure 1 of Dunham in responding to 
a host for a backup routine. Again, locating storage capacity on the primary volume is in 
response to a restoration routine, not a backup routine, Dunham at col. 21, 11. 16-63. 

[001 1] The Office Action states that Dunham discloses "de-allocating volumes in the 
primary storage after modification access" and cites column 6, line 33 to column 7, line 17 of 
Dunham. Office Action at p. 3. The Applicants disagree. The cited text in Dunham discusses 
organizing a primary directory 26 for a snapshot copy. Dunham at col. 6, 1. 33 to col. 7, 1. 17. 
When a write request alters data on the primary, the original data is copied to another location on 
the primary. Id. Flags and pointers keep track of which tracks of the primary were modified to 
be able to access the snapshot copy. Id. The citation discloses that by combining the original 
data copied to another portion of the primary when corresponding data was modified and data on 
the primary that has not been modified a full snapshot is available without creating two complete 
copies of the primary data. Id. The snapshot copy can then be written to the secondary and the 
tracks occupied by the original data copied to another location of the primary can be released for 
general storage. Id. The cited text has nothing to do with the recovery process of Figure 1 5 of 
Dunham and nothing at all to do with de-allocating storage volumes of a storage pool. 
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[0012] The Office Action states that Dunham discloses the incremental log and cites the 
primary directory 26, Figure l and column 6, lines 33-40 of Dunham in support. The Applicants 
disagree. As stated above, the citation has to do with a snapshot copy operation, not mapping a 
virtual address assigned to incremental storage data to a physical storage address of a storage 
volume in the storage pool. Incremental data is not equivalent to snapshot data. The "log 
structured file" includes virtual mapping within the primary volume and does not relate to the 
secondary volume other than in the sense that storage locations in the primary are marked as 
available after the contents of the primary storage locations are copied to the secondary storage. 
Dunham at col. 6, l. 63 to col. 7, l. 17. The incremental log of claim 1 maps virtual addresses of 
incremental data to physical addresses of a storage volume of the storage pool. Application at 
amended claim 1, H 49. The cited text in Dunham only involves a snapshot copy of the entire 
primary storage, not incremental storage data. 

[001 3] The Applicants respectfully assert that Dunham does not anticipate claim 1. In 
addition, the amendments to claim 1 further distinguish Dunham from amended claim 1 . The 
Applicants respectfully assert that claim 1 is in condition for allowance. The Applicants also 
respectfully assert that independent claims 12, 16, 23, 24, and 28 are similar in scope to claim 1 
and that the arguments presented above for claim 1 are equally applicable and therefore claims 
12, 16, 23, 24, and 28 are allowable. In addition, the Applicants assert that claims 2-1 1 , 13, 15, 
17-22, 25, and 26 are allowable as being dependent on allowable independent claims. 

[0014] In regard to claim 3, the Office Action states that Dunham discloses 'the storage 
pool management module is further configured to allocate and de-allocate a portion of a storage 
volume to the storage pool" and again cites Figure 15 and column 21, lines 16-63. Office Action 
at pp. 9-10. The Applicants disagree. As stated above, Figure 15 of Dunham describes a 
restoration process and assigning a virtual volume to spare storage capacity of the primary 
storage. Dunham at Fig. 15, col. 21, 11. 16-63. Claim 3 recites allocating and de-allocating a 
portion of the storage pool, which the Office Action cites as being equivalent to the secondary 
storage. See Office Action at p. 3. The Applicants respectfully assert that claim 3 is not 
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anticipated by Dunham and is in condition for allowance. The same argument is applicable to 
claim 20 and the Applicants respectfully assert that claim 20 is also in condition for allowance. 

[0015] In regard to claim 5, the Office Action states that Dunham discloses that 4t the 
storage pool management module allocates and de-allocates storage volumes without user input" 
and states that "once the backup policy is set, the host communicates with the backup agent 
irrespective of the user input in order to effectively manage and backup the volumes (Fig. 15)." 
Office Action at p. 10. The Applicants disagree. While some functions of backing up a volume 
and restoring a volume may be automated, Dunham only discusses backing up and restoring a 
volume in response to user input or to an application. See e.g. Dunham at col. 1 1, 1 25 to col. 12, 
1. 23. In addition, claim 5 in conjunction with claim 1 makes clear that the storage pool 
management module allocates and de-allocates storage for an incremental storage operation, not 
the fall backup and restore operations taught by Dunham. The Applicants respectfully assert that 
claim 5 is in condition for allowance. 

[0016] In regard to claim 6, the Office Action states that Dunham discloses "the storage 
pool management module is further configured to allocate a second storage volume to the virtual 
volume in response to a reduction in available space on a first storage volume" and cites Figure 
15 of Dunham. Office Action at p. 10. The Office Action states that "more volumes will be 
allocated to create sufficient memory to store the copied data." Id. The Applicants disagree. 
The process described in relation to Figure 15 only allocates storage on the primary if there is 
enough spare capacity to fit the entire backup copy being restored. Dunham at Fig. 15, col. 16- 
63. If there is not sufficient spare capacity, the process accesses the backup copy on the 
secondary storage. Id. at col. 22, 11. 4-20. This is opposite of the limitation recited in claim 6. In 
claim 6, storage capacity is added in response to a reduction of storage capacity. In Dunham, 
storage is allocated for storing a backup only if the spare capacity is above the amount required to 
store a copy of the backup. Id. at Fig. 15, col. 16-63. If storage capacity on the primary is 
reduced below what is required, storage space on the primary is not allocated. Id. at col. 22, 11, 
4-20. The Applicants respectfully assert that claim 6 is not anticipated by Dunham and is in 
condition for allowance. 
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[0017] In regard to claim 10, the Office Action states that Dunham discloses "the storage 
pool management module is further configured to increase the storage capacity in response to the 
available storage capacity increasing above a first storage capacity threshold and to decrease the 
storage capacity in response to the available storage capacity decreasing below a second storage 
capacity threshold" and cites again Figure 15 while stating that S4 the allocation and de-allocation 
is dynamically determined based on available storage capacity." Office Action at p. 11. The 
Applicants disagree. 

[0018] Figure 15 and the related text do not mention first and second storage capacity 
thresholds. Dunham at Fig. 15, col. 21, 1. 16 to coL 22, 1. 20. The only determining factor 
mentioned in Dunham for allocating storage in the primary, or not, is whether the primary has 
enough storage capacity to fit the backup copy. Id. In addition, Figure 15 and the cited text do 
not discuss allocating or de-allocating storage capacity, but instead only discuss allocating 
already available spare capacity on the primary storage and then de-allocating the same storage 
when the backup restoration is complete. Id. The Applicants respectfully assert that claim 10 is 
not anticipated by Dunham and is in condition for allowance. 

REJECTION OF CLAIM 14 UNDER 35 U.S.C. §103(a) 

[0019] The Office Action rejected claim 14 under 35 U.S.C. § 103(a) as being 
unpatentable over Dunham in view of Asano. The Applicants respectfully traverse this rejection. 
The Examiner bears the initial burden of establishing a prima facie case of obviousness. MPEP 
at § 2142. The prior art reference (or references when combined) must teach or suggest all the 
claim limitations. MPEP at § 2142. The Applicants respectfully assert that Dunham and Asano 
combined fail to teach or disclose each element of the claimed invention as required under 35 
U.S.C. § 103(a). As stated above, Dunham fails to disclose all of the elements of claim 12 and 
the Applicants respectfully assert that claim 12 is in condition for allowance. The Applicants 
respectfully assert that the elements missing from Dunham in claim 12 are not present in Asano. 
Because claim 14 depends from claim 12, which is an allowable claim, the Applicants assert that 
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claim 14 is patentable over Dunham and Asano and is in condition for allowance. See, In re 
Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988); 

[0020] Should additional information be required, the Examiner is respectfully asked to 
notify the Applicants of such need. If any impediments to the prompt allowance of the claims 
can be resolved by a telephone conversation, the Examiner is respectfully requested to contact the 
undersigned. 



Date: October 10. 2006 
8 East Broadway, Suite 600 
Salt Lake City, UT 841 11 
Telephone (80 1)994-4646 
Fax (801) 53 1-1929 



Respectfully submitted, 




Bruce R. Needham 
Reg. No. 56,421 
Attorney for Applicants 
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